home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1994 March / Internet Info CD-ROM (Walnut Creek) (March 1994).iso / inet / rfc / rfc704 < prev    next >
Encoding:
Text File  |  1991-04-20  |  7.3 KB  |  173 lines
  1. Network Working Group                                Paul J. Santos, Jr.  (BBN)
  2. Request for Comments 704                                              Sept 1975
  3. NIC #33490
  4.  
  5.  
  6.  
  7.              IMP/Host and Host/IMP Protocol Change
  8.  
  9. This note is a revision of RFC 687 and sketches the design
  10. of an expansion to the IMP/host and host/IMP protocol which will
  11. include among other things the possibility of addressing hosts on
  12. more than 63 IMPs. Our intention in this expansion is to correct
  13. certain existing limits without fundamental changes in the
  14. philosophy of the IMP/host protocol; i.e., while many issues
  15. which would represent fundamental changes to the IMP/host
  16. protocol are presently under discussion in the world-wide
  17. packet-switching community, we are not able to undertake massive
  18. fundamental changes on a time scale compatible with the short
  19. term needs for network improvement (e.g., already there are 62
  20. IMPs).
  21.  
  22. The following paragraphs cover each of the major
  23. characteristics of the expanded protocol. A knowledge of Section
  24. 3 of BBN Report 1822 is assumed. As is discussed below, the
  25. expanded protocol is backwards compatible.
  26.  
  27. 1. Expanded Leader Size. The leader will be expanded from two
  28. to six 16-bit words. This will provide space for necessary field
  29. expansions and additions. The expansion of the IMP/host
  30. (host/IMP) leader to 96 bits from 32 causes word-boundary
  31. problems for some hosts. To be able to deliver messages between
  32. two hosts of which one is using the old protocol and the other
  33. the new, without shifting the data in the IMP words, it is
  34. necessary that the data (i.e. the first bit of the host/host
  35. leader) start at an even multiple of 8-bit bytes from the
  36. beginning of the entire message. On the other hand, each host
  37. prefers (in fact requires, if no shifting is to be performed by
  38. the host) that the combined host/IMP (IMP/host) and host/host
  39. leaders occupy some integral number of machine words (defined as
  40. the smallest sequence of bits that can be independently accessed
  41. by the host/IMP interface). With a total host/IMP (IMP/host) and
  42. host/host leader of 136 bits, only machines with 8-, 16-, 32-,
  43. and 64-bit words will find the leader size suitable. To simplify
  44. things for machines with other word lengths, a provision of the
  45. protocol permits each host to tell its IMP a number of 16-bit
  46. padding words to be inserted between the host/IMP (IMP/host) and
  47. host/host leaders. This padding will be stripped off during
  48. host-to-IMP processing by the IMP, and added in during
  49. IMP-to-host processing. Thus, for instance, 24-bit machines can
  50. specify one 16-bit word of padding, and 10- and 36-bit machines
  51. can specify five 16-bit words.
  52.  
  53. 2. Expanded Address field. The address field will be expanded
  54. to 32 bits, 16 bits of IMP address, 0 bits of host address, and 8
  55. bits for (future) network address. This expansion is adequate
  56. for any forseeable ARPA Network growth.
  57.  
  58.                                  -1-
  59.  
  60. 3. New Message Length Field. A new field will be added which
  61. will allow the source host to optionally specify the message
  62. length (in bits) to the IMP subnetwork. The IMP subnetwork may
  63. be able to use this information (when available) to better
  64. utilize network buffer storage. The destination host may also be
  65. able to use this information to better utilize its buffer
  66. storage. This field will be 16 bits wide. There will be
  67. provision for expanding the maximum number of packets per message
  68. to 16 from the present 8.
  69.  
  70. 4. Expanded Handling Type Field. The handling type field which
  71. now is used to distinguish between priority and non-priority
  72. message streams, etc., will be expanded to eight bits. This
  73. expanded field will provide for the possibility of a number of
  74. parallel message streams having different handling
  75. characteristics between pairs of hosts; e.g., priority,
  76. non-priority, varying numbers of packets per message (see below),
  77. a message stream requiring guaranteed capacity, etc. Only the
  78. old-style priority and non-priority handling types will be
  79. available in the initial implementation of the expanded protocol.
  80.  
  81. 5. Source Host Control of Packets per Message. The possibility
  82. will exist for the source host to specify a message stream which
  83. will use a given number of packets per multi-packet message (e.g,
  84. two packets per message or five packets per message). Since the
  85. IMP network will not have to use eight packet-buffers for
  86. reassembly purposes, as at present, this may result in better
  87. services for such hosts. This will help users who need both low
  88. delay and high throughput. Since this facility is orthogonal to
  89. and of lower priority than the address expansion, it will be
  90. implemented after the other proposed basic changes.
  91.  
  92. 6. Unordered (type-3) Message Change. Unordered messages will
  93. be indicated by a subtype of the type O message, rather than by a
  94. separate message type as at present. This is compatible with the
  95. need to check the host access control capabilities of all
  96. messages. This will provide a slight backward incompatibility
  97. for the three or so hosts which presently use type-3 messages in
  98. their research.
  99.  
  100. 7. Change in Format of Fake Host Addresses. The For/From IMP
  101. bit will be eliminated. The fake host addresses will be the four
  102. highest host numbers (e.g., IMP Teletype will be host 252).
  103.  
  104. 8. Addition of a Parameter to the IMP to Host NOP. The IMP to
  105. host NOP will have added to it a parameter specifying the address
  106. (IMP and host number) of the host.
  107.  
  108. 9. Backward Compatibility. The old and new formats will be
  109. supported in parallel in the IMPs for the foreseeable future to
  110. allow gradual phaseover of host software. A host will be able to
  111. specify to its IMP whether the old or new formats are to be used;
  112. thus, it will be possible for the host to specify switching back
  113. and forth between the two modes for debugging purposes. The
  114.  
  115.                                  -2-
  116.  
  117.  
  118. specification of the mode to be used will be possible via a
  119. proper choice of format in the host to IMP NOP message; the IMP
  120. will use the mode of the host to IMP NOP message the IMP has
  121. received. Further, a host may select to use either the old or
  122. new format without needing to know more about the other format
  123. messages than to discard them should they arrive. The IMP will
  124. initialize by sending several NOP messages of each type to give
  125. the hosts its choice. Although a host not implementing the new
  126. format will not be able to address hosts on IMPs with IMP-number
  127. greater than 63, the IMPs will wherever possible do the
  128. conversion necessary to permit hosts using the old format to
  129. communicate with hosts using the new format and the reverse.
  130.  
  131. 1O. Non-blocking Host Interface. A mechanism will be provided
  132. which allows the IMP to refuse a message from a host without
  133. blocking the host interface. This mechanism will permit the IMP
  134. to gather the necessary resources to send the refused message and
  135. then ask the host to resend the message. Finally, the host will
  136. be permitted to ask to be able to send a message and be notified
  137. when it is possible without requiring the message to actually be
  138. sent and refused. Again, as in point 5 above, this facility will
  139. be added after the other more basic changes have been
  140. implemented.
  141.  
  142. 11. Maximum Message Length. The maximum number of bits of data
  143. in a single-packet message may be reduced by a few bits.
  144.  
  145. We are now producing a draft version of the necessary
  146. changes to Report 1822 and will circulate it so that host
  147. programmers can begin to make their preparations.
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170.  
  171.  
  172.                                  -3-
  173.